What is Style?

A central aspect of architectural design is the use of recurring organizational patterns and idioms| or architectural styles [GS93, PW92, MG92, GHJV94]. Examples include generic system organizations such as those based on data ow or layers, as well as speci c organizational structures such as the classical decomposition of a compiler, the OSI communication stack, and the MVC user interface paradigm. The principled use of architectural styles has a number of practical bene ts. First, it promotes design reuse: routine solutions with well-understood properties can be reapplied to new problems with con dence. Second, it can lead to signi cant code reuse: often the invariant aspects of an architectural style lend themselves to shared implementations. Third, it is easier for others to understand a system's organization if conventionalized structures are used. For example, even without giving details, characterization of a system as a \client-server" organization immediately conveys a strong image of the kinds of pieces and how they t together. Fourth, use of standardized styles supports interoperability. Examples include CORBA object-oriented architecture [Cor91], and event-based tool integration [Ger89]. Fifth, by constraining the design space, an architectural style often permits specialized, style-speci c analyses. For example, it is possible to analyze pipelter systems for schedulability, throughput, latency, and deadlock-freedom. Such analyses might not be meaningful for an arbitrary, ad hoc architecture { or even one constructed in a di erent style. Sixth, it is usually possible to provide style-speci c visualizations: this makes it possible to provide graphical and textual renderings that match engineers' domain-speci c intuitions about how their designs should be depicted. Unfortunately, the use of architectural styles is almost completely ad hoc. It is virtually impossible to answer with any precision what aspects of system design can/should be speci ed by a style, to compare di erent styles based on their properties, to relate systems developed in di erent styles, to develop general-purpose tools for exploiting style, to select appropriate styles for a given problem, or to combine several styles to produce a new one. Evidentally what is needed (among other things) is a more rigorous basis for understanding architectural style and ways to exploit it. In this paper I brie y outline and compare three approaches to providing such a basis.